The Evolved Packet System (EPS) is known by the brand name long term evolution (LTE) network. It comprises the E-UTRAN Radio Access network and the Evolved Packet Core (EPC). The 3rd generation partnership program (3GPP) is in the process of defining enhancements to the evolved packet system.
Policy and Charging Control (PCC) has a key role in the way users' services are handled. It provides a way to manage the service related connections in a consistent and controlled way. It determines e.g. how bearer resources are allocated for a given service, and quality of service (QoS) characteristics of the bearers. The parameters may be set dynamically for each service and even each user separately. For details of the PCC for 3GPP release 8, see 3GPP technical specification (TS) 23.203.
FIG. 1 shows the PCC functions and interfaces in one operator's network of 3GPP release 8 (taken from H. Holma and A. Toskalla, “LTE for UMTS”, John Wiley & Sons, (2009)).
A user equipment (UE) signals a request for a service in the Service Layer, and the application function (AF) residing in that layer contacts the Policy and Charging Rules Function (PCRF) for appropriate bearer resources via the Rx interface. The PCRF is in charge of meeting decisions on what PCC to use for the service. If subscriber specific policies are used, the PCRF may enquire the subscriber related policies from the subscription profile repository (SPR) via the Sp interface.
The packet data network gateway (P-GW) comprises e.g. the Policy and Charging Enforcement Function (PCEF). The PCRF pushes the PCC rules to the PCEF via the Gx interface. The PCEF is responsible for enforcing the PCC rules, e.g. setting up the corresponding dedicated bearers, modifying the existing bearers, ensuring that only authorized service flows are allowed, and QoS limits are not exceeded.
3GPP SA2 has a Rel-10 study item on “Policy solutions and enhancements”. Studied items are documented in technical report TR 23.813. Key issue 4 “Service Awareness and Privacy Policies” of the study deals with the traffic detection for policy and charging control purposes. The traffic detection functionality may be implemented either as collocated with PCEF or as a standalone entity. The standalone solution aims at avoiding performance and scalability problems that may occur in a solution where the traffic detection is integrated in the same entity/gateway with the PCEF.
When there is no interaction between the application function AF and PCRF, the network may not be aware of the usage of such services by the UE even though the network may have defined policies related to the services. User experience can be enhanced, if the network becomes aware of such services and the network is able to apply service specific policies.
Traffic Detection Function (TDF), based on deep packet inspection, can be applied in a network to support policy and charging control (by PCRF) for services for which the PCRF does not get related service information from an AF/P-CSCF. Such conditions may occur for example when the AF does not have an interface to the PCRF (refer to the Rx interface between AF/P-CSCF and PCRF; P-CSCF: Proxy call session control function) or when there is no explicit service level signaling and hence no interaction between the Application Function (AF) and PCRF or when filters related to a service have not been installed in the PCEF.
The TDF indicates the start and stop of the detected services to the PCRF. The PCRF provisions/modifies/deletes PCC rules for the detected service.
The use of the service traffic detection mechanism may be combined with privacy policies (as suggested in the draft TR 23.813 by 3GPP SA2), i.e. the PCRF shall check upon an IP-CAN session establishment whether the use of the traffic detection mechanism is allowed for a given user, and if yes, which services shall be monitored and detected. The PCRF then instructs the TDF on which services it should detect and report.
Furthermore, the use of the service traffic detection mechanism, in particular if combined with privacy policies, may require user/subscriber consent, and for this purpose the PCC architecture has to be extended to include user privacy policies (e.g. the PCRF should check the subscription data in the SPR upon an internet protocol-connectivity access network (IP-CAN) session establishment, if the PCEF indicates the support of the traffic detection function).
Gx and Rx based interfaces are proposed in the TR 23.813 as candidates for the interface between the PCRF and TDF. When TDF and PCEF are collocated, the Gx based solution would be an extension to the current Gx interface/protocol and an Rx based solution would mean an extra Rx based protocol (in addition to Gx) between the TDF/PCEF and PCRF. A standalone TDF would mean a new (possibly Gx or Rx based) protocol between the standalone TDF and PCRF.
For example, according to 3GPP technical report (TR) 23.813 v0.3.0, the following enforcement actions may be applied to the traffic by the PCEF:                a. Permit Unrestricted—the detected service/flow is allowed to continue without further policy action        b. Block—the detected service/application flows are blocked (or the “gate is closed”)        c. Shape—apply some regime of traffic shaping to the detected service/application flows (e.g. to bandwidth limit for P2P file sharing flows)        d. Redirection—Redirect detected flows to another controlled address (e.g. redirect to a top-up/service provisioning page). This may not be possible for all types of detected flows (e.g. this may only be performed on specific HTTP based flows).        
Such policy enforcement actions (e.g. gating, shaping, redirection) may be activated immediately at the TDF after the detection of a given service. Normally these enforcement actions are performed by the PCEF.
In the context of this application, the ability to perform such and other related enforcement actions are named capabilities.